【AWS SAA対策 Udemy】 サーバレス
密結合構成だと単一障害点が多く、障害発生時に対応が大変
なので基本的な構成は疎結合でコンポーネントをつなげて対応する。
ELB自体はサーバー間とのトラフィック調整と連携をELBを起点に結ぶ事で疎結合化を実現
SQSの概要
Amazon SQS は、高スループットのシステム間メッセージング用のキューイングサービスです。キューを使用して、負荷の高いプロセスを分離し、作業のバッファリングとバッチ処理を行うことができます。Amazon SQS は、マイクロサービスとサーバーレスアプリケーションが処理するまでメッセージを保存します。
SQSのキューイングによる通信で、インスタンス間連携を結ぶ事で疎結合を実現する
サーバー間でSQSをつなげる事で対応
アプリケーション間ではSQSや、MQ通信で連携する
SQLはポーリング型のサービス
複数のプログラム間通信の対し、一定のタイミングのお問い合わせがあった場合に総受信処理を行う通信方式。
Producer送信処理→Polling Consumer受信処理
中継所で通信事項で判断する。
SQSはキューを溜め込んで、受信側に通信して問題なかったら送信を行う
無料枠と課金枠になっている。
基本的には256KBまでの軽いデータしか利用できず、60秒から14日間メッセージを保持する。
削除されないメッセージはデフォルトで4日間保持します。保持期間は60秒から14日の間で変更可能です。
キュー方式
標準キュー
順番通りに処理と1だけのメッセージングをなるべく実行する
FIFO
最初に入ったキューを確実に実行する
Poling方式
Short Poling
キューが空の場合でも即時にリターンする
Long Poling
キューが空の場合はタイムアウトまで待つ
デッドレターキュー
ずっと残っていたメッセージを別キューに移動し、正常に処理できなかったメッセージを隔離できる
visibility timeout
新しいメッセージを指定時間、見えなくする
複数インスタンスを利用する際に優先的に処理して欲しい、受信インスタンスを指定する事が可能
spotインスタンスを利用している場合に効果的
SNSの概要
Amazon SNS は、マイクロサービス、分散システム、およびイベント駆動型のサーバーレスアプリケーションの分離を可能にする、可用性が高く耐久性に優れたセキュアな完全マネージド型の pub/sub メッセージングサービスです。Amazon SNS は、高スループット、プッシュベース、多対多のメッセージングのためのトピックを提供します。
SNSのアプリケーション間通信により、インスタンス間連携を結ぶ事で疎結合を実現する
SNSはプッシュ型通信サービスで他のサービスとの非同期通信を行っている
送信側はトピックを作成して、受信側はポリシーを指定する事で制御された非同期通信を実現する
iOSのPush通知などで使える
メッセージ通信処理は保証されてなく、取り消しができない。
配信ポリシーによる再試行を実施できる。
連携できるサービス
CloudWatch
Billung Alert
Amazon SES
Amazon S3
Amazon Elastic Transcoder
動画変換処理完了/失敗時の通知
SQSとの使い分け
SNSは永続ではなく、プッシュ型配信方式(一方通行)、クライアントがサブスクライブする
SQSは永続性あり、ポーリング型通信方式、クライアントが送受信する。
SESの概要
Amazon Simple Email Service (SES) は、デベロッパーが任意のアプリケーションでメールを送信できるようにする、費用対効果の高い、柔軟でスケーラブルなメールサービスです。Amazon SES はすぐに設定でき、トランザクション、マーケティング、大量の E メール通信など、いくつかの E メールのユースケースをサポートします。 Amazon SES の柔軟な IP デプロイと E メール認証オプションは、配信可能性を高め、送信者のレピュテーションを保護すると同時に、送信分析で各 E メールの影響を測定します。Amazon SES を使用すると、安全、グローバル、大規模に E メールを送信できます。ref:https://aws.amazon.com/jp/ses/ Amazon Email Service
メール送受信処理、バウンス処理などが簡単に利用できる
HTTP REST API
APIでメール送受信処理ができる
認証はAWSのアクセスKeyとシークレットKeyでできる
SMTP エンドポイント
SMTPを利用する場合にこちらを使う
TLSが必要
認証: 専用IAMユーザーを作成して、そのクレデンシャルを使用
SESを使ってメール通知でS3やLamdaで利用が可能になる
SESを使う場合はドメインと、メールの事前申請が必要
ちょい時間がかかる
サーバーレスアーキテクチャ
EC2インスタンスを使うのではなくLamdaを使ってコンピューティングサービスを構築する
低コストで疎結合を可能にさせる
サービス化→疎結合→サービスレス
マイクロサービス化...とあるが、それができているのはメルカリぐらいなぁ
サーバレスはAPI GatewayでAPI通信によりコンポーネント間を通信する
サーバレスは「本当にこのインスタンスは必要か?」が大事になってくる
Lamda
これは使ってみたい!
AWS Lambda はサーバーレスコンピューティングサービスで、サーバーのプロビジョニングや管理、ワークロード対応のクラスタースケーリングロジックの作成、イベント統合の維持、ランタイムの管理を行わずにコードを実行できます。Lambda を使用すれば、実質どのようなタイプのアプリケーションやバックエンドサービスでも管理を必要とせずに実行できます 。
アプリケーションコードを実行できる
Lamdaに置き換えてサーバレスに実行する。
特徴
実行基盤はAWSが管理
オートスケール可能
100ミリ単位でコード実行するので、低課金
Lamdaでコードを記述し、アプリから呼び出す
Pushモデル
S3/SNSなど、AWSサービスと連携する際にカスタムイベントを直接実行する
Pullモデル
DynamoDB、Kinesisなど、Lamdaに対して直接的にイベントを発行しない為、Lamdaでそれらをポーリングし、実行を行う
Lamda自体からPullしてくる
処理タイミング
非同期実行
リクエストが正常に受け付けられたというレスポンスが返ってくる
同期実行
実行完了時にLamdaファンクション内でセットしたレスポンスが返ってくる
Lamdaのパーミッション
Excectuon :実行時の権限
Invocation:外部からLamdaのファンクションを実行する際の権限
ブループリント
サンプルコード集を利用する事が可能
スケジュール機能
バージョニング機能
作成時や更新時にpubulishパラメータによりバージョンが発行される
VPCへのアクセス
Elastic Network Intarnetを使ってアクセスでき
Lamda Layer
5つまで利用可能
ALBのバックエンドにロードバランサーとして呼び出す事ができる。
CroudFront + Lamd = Lamdaエッジ
めちゃくちゃすごい
API Gateway
フルマネージド型サービスの Amazon API Gateway を利用すれば、デベロッパーは規模にかかわらず簡単に API の作成、公開、保守、モニタリング、保護を行えます。API は、アプリケーションがバックエンドサービスからのデータ、ビジネスロジック、機能にアクセスするための「フロントドア」として機能します。API Gateway を使用すれば、リアルタイム双方向通信アプリケーションを実現する RESTful API および WebSocket API を作成することができます。API Gateway は、コンテナ化されたサーバーレスのワークロードやウェブアプリケーションをサポートします。ref:https://aws.amazon.com/jp/api-gateway/ AWSでAPIを簡単に作成できる
Lamdaと密接に統合されている。
webアプリ→API Gateway→Lamda→AWSサービスを呼び出す
最大数十万個のAPI同時呼び出し・受付が可能です。